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[57] ABSTRACT 

A system and method for creating and modifying intelli- 
gent telephone network call processing logic trees 
which can be customized for individual customers and 
created in a user-friendly visual environment (10, 15, 
FIG. 3-5). Service primitives are defined as logical 
graph nodes (20, FIG. 2, FIG. 3) which can be visually 
assembled into logic trees (FIG. 5) which represent the 
service logic flow and which provide default values for 
all service options. Higher level nodes, assembled from 
a plurality of service primitives, can likewise be defined 
and stored (12, 13, 19) for later use as entities in defining 
yet further call processing logic trees. These call pro- 
cessing logic trees are interpreted to allow the service 
control point computers (17) to implement the services 
in the switched telephone network (18) by sequentially 
executing the specified call processing primitives. A 
library (12, 13, 19) of defined nodes and defined node 
assemblies which represent service features can thus be 
made available to permit graphical manipulation into 
complete logic trees representing new services. These 
logic trees are then interpreted by generic programs in 
the service control point to actually provide the de- 
scribed services. 

17 Claims, 4 Drawing Sheets 
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FIG. 2 
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FIG. 5 
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to implement and customize such services without the 

VISUAL PROGRAMMING OF TELEPHONE need for new switch software or hardware. Currently, 

NETWORK CALL PROCESSING LOGIC this INCPL is custom-developed for each new service 

by a service designer, usually associated with the ser- 

TECHNICAL FIELD 5 vice provider, installed in the intelligent network ser- 

This invention relates to the creation and the provi- vice implementing component and supported by a ser- 

sioning of special customized telephone network ser- vice management system for that service. Thus, instead 

vices for telephone subscribers and, more particularly, of the software to support a new service coming from a 

to a portable, visually programmed call processing logic switch vendor, it can now come from a service vendor, 

interface for creating and provisioning such customized 10 making it possible to reduce the interval between ser- 

services. vice concept and service offering. Unfortunately, a 

BACKGROUND OF THE INVENTION ^ *T h Stfll Tt *™edto desi 8" custom ^ 

v implement each new service. Moreover, since such 

New telephone services are continually being devel- service designs are not highly portable, further delays 

oped by telephone service providers in order to meet 15 arise due to the need to provide widely distributed 

the needs of their customers. As such services become software elements to support the new service in a wide 

available, the telephone companies, subscribers and the variety of different environments, 
users seek yet further improvements in these services. 

Special services such as 800 service, 900 service, and SUMMARY OF THE INVENTION 
Private Virtual Networks (PVN) are only a few of the » i n accordance with the illustrative embodiment of the 
possible services being offered. Other services might present invention, these and other problems are over- 
well be conceived and might well find extensive use, come by providing a user-friendly environment in 
Unfortunately, however, new telephone services have which indigent network service primitives can be 
heretofore required long and expensive design, testing assembled into telephone services utilizing the graphic 

fiSSET n ^ capabilities of a computer workstation. If a complete 

terns services are typically provided in the public tele- tel hone b ^ d M a h ^ of 

proach to providing such special services is the intr£ 25^2? "J™ T T£ V ' ^TT 
duction into the telephone network of a service imple- 30 "^menting component and the edges represent the 
menting network element which interacts with the tele- 0r * er * e ^ 10n °f *«e primitives. Both action 
phone network so as to implement the telephone ser- nod « a «<* decision iiodes can be defined in terms of the 
vices. Such service implementing network elements are **vice primitives and stored for later use in 
variously called Service Adjuncts (SAs), Service designing a new telephone service. Moreover, with this 
Switching Points (SSPs) and Service Control Points 35 representation, the new telephone service can be dis- 
(SCPs). One such Service Adjunct is disclosed in S. M. P laved 88 a " tree " of such nodc - Such a tree dis P ] ay can 
Lin and J. F. Rizzo U.S. Pat % No. 4,878,240, granted be manipulated graphically to create and alter the logic 
Oct. 31, 1989. A typical Service Switching Point is of a s^v"*- An interpreter program, designed for a 
disclosed in J. J. Bernardis U.S. Pat. No. 4,782,517, particular service implementing component, imple- 
grantedNov. 1, 1988. Finally, a typical Service Control 40 ments such display representations with the available 
Point is disclosed in J. O. Boese et al. application Ser. adjunct service primitives. In accordance with this in- 
No. 453,042, filed Dec. 12, 1989. Each such service vention, telephone services can be created, manipulated 
implementing network element is equipped with a set of and altered by simple, user-friendly graphical manipula- 
software-implemented service primitives which can be t \ on - Not onl y ca n intelligent network service primi- 
combined in various ways to implement a number of 45 tiv es be assembled graphically into new services, but 
telephone services. A set of such primitives for a Ser- service features can be defined as assemblies of such 
vice Adjunct is disclosed in the above-mentioned Lin et intelligent network service primitives and, once de- 
al, patent. Another set of primitives for a Service signed, stored in a library as a single node to be invoked 
Switching Point is disclosed in the above-mentioned and reused as a single entity in designing a plurality of 
Bernardis et al. patent. Yet another set of such primi- 50 future services. 

tives for a Service Control Point is disclosed in "Busi- More particularly, graphical images or icons on a 
ness Services Database (BSDB): A Service Control display screen are used to represent a reusable library of 
Point (SCP) Application Designed to Support Private user-defined telephone service primitives. These images 
Virtual Network (PVN) Service, "Technical Advisory or icons can be manipulated graphically so as to assem- 
TA-TSY-000460, Issue 2, February 1988, published by 55 ble the images into logical trees representing new ser- 
Bell Communications Research, Inc., Red Bank, N.J. vices or new service features. Once fully assembled, the 
All of these sets of service-implementing primitives are, electronic representation of the graphical service tree 
as a group, generally equivalent, although each is imple- or service feature tree can be interpreted so as to actu- 
mented in a slightly different way. ally implement the service or service feature. In this 
A telecommunications network including such pro- 60 way, new telephone services can be designed and imple- 
grammable special service implementing components is mented much more quickly than in the prior art and 
called an "intelligent network." Such networks make it thus save much of the expense previously associated 
possible to offer useful and profitable new services such with telephone service design and deployment. In addi- 
as 800 service, Alternate Billing service and Private tion, the extremely high level representation of tele- 
Virtual Network service. Intelligent Network Call Pro- 65 phone services implicit in the graphical service trees is 
cessing Logic (INCPL) is the name given to the soft- an extremely portable mechanism for quickly and easily 
ware that "stitches together" the appropriate service deploying such services without extensive reworking of 
primitives to enable the Intelligent Network mechanism service implementing code. Indeed, the simplicity, 
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speed and flexiblity of telephone service design and service nodes which are used to design and implement a 
implementation provided with the present invention particular advanced telephone service in the system of 
can be exploited to allow each individual telephone user FIG. 1; and 

to custom design telephone services exactly matching FIG. 5 is a graphical representation of a display 
the needs of the customer. 5 screen used to customize a logical tree template of ser- 

The present invention makes possible dynamic graph- vice primitives by specifying all of the customer- 
ical creation, customization and provisioning of new dependent variables required to implement a particular 
call processing services. Using both simple nodes, here- new service for a particular customer in the system of 
into called primitive nodes and consisting of, primitives FIG. 1. 

and complex nodes that are user-defined constructed 10 To facilitate reader understanding, identical refer- 
nodes and are called user defined service feature nodes, ence numerals are used to designate elements common 
new services can be defined rapidly and with great ease. to the figures. 
A new service is created visually as a logic tree with 

nodes defined to represent a high-level abstraction of DETAILED DESCRIPTION 

the primitive call processing actions or call processing 15 Referring more particularly to FIG. 1 of the draw- 
decision points or combinations of such primitive ac- ings, there is shown a general block diagram of an intel- 
tions and decision points. This tree, or the electronic ligent network telephone service design and deploy- 
representation of the tree, is called a Call Processing ment system comprising a workstation 10 for designing 
Record (CPR) since it defines exhaustively the process- new telephone services in accordance with the present 
ing necessary to provide an individual call with the 20 invention. As will be described hereinafter, workstation 
defined service. Service providers, as well as subscrib- 10 includes graphical facilities for defining customer 
ers themselves, can customize and provision the graphi- special service nodes in terms of service control point 
cally defined service to satisfy specific customer needs primitives, bounding new special services in terms of 
by dynamically modifying and parameterizing the rele- the thus defined nodes which can be used for that ser- 
vant graphical call processing record trees. The thus 25 vice, and assembling these telephone service nodes into 
provisioned call processing records representing the templates or assemblies of call processing logic units 
service can then be translated from the user-friendly capable of providing the new telephone special ser- 
visual format to a rigorous program-generating format vices. Service creation process 11 provides the software 
which can be genetically interpreted by existing service for supporting these facilities and includes standard 
implementing components. The distribution and instal- 30 window processing capability as well as mouse or other 
lation of such call processing records to appropriate visual selection apparatus support, and is typically 
service implementing components in an intelligent net- stored in the program memory of workstation 10. Stor- 
work enables the thus-described service to become age device 12 stores a library of the electronic represen- 
instantly available to telephone subscribers. tations of all of the nodes previously specified, both 

There are three steps in this service specification 35 simple primitive nodes and more complex, user-defined 
process: 1) defining the nodes, 2) establishing which service feature nodes. Storage device 13 stores the defi- 
nodes can be used in a particular service, and, 3) creat- nitions of all of the services defined at workstation 10, 
ing call processing records defining a particular service where a service definition is simply the specification of 
using the nodes that have been defined, and to which which of the defined nodes (primitives) can be used to 
can be added the customer-specific parameters neces- 40 implement a particular service. Storage device 19 stores 
sary to completely specify the service. These three steps templates of multinode fully designed services as call 
can be iterated interactively to improve the quality of processing records. In the present application, a "tem- 
the resulting service, to remove "bugs," or to provide plate" is a fully designed service, but without all of the 
new features and capabilities. variable parameters which are dependent on the actual 

Other aspects of a service creation and provisioning 45 customer using the service. Although shown as separate 
system are disclosed and claimed in the copending ap- storage devices, stores 12, 13 and 19 can be contained in 
plications of D. L. Babson, J. A. Bajzath, Jr. and T. C. a single storage device. 

Ely, Ser. Nos. 629,371, 629,389, 629,390 and 629,447, all The present invention contemplates three steps in 
filed of even date herewith and assigned to applicants' creating new services, defining graphical nodes from 
assignee. 50 which services can be assembled (node definition), pre- 

BRIEF DESCRIPTION OF THE DRAWINGS ? Cribi . ng T*?*? 0 *" S™ be u . se . d in a P articu,ar scrvice 

(service definition) and prescribing the logical interrela- 

A complete understanding of the present invention tionships of the various nodes necessary to produce the 
may be gained by considering the following detailed desired service (call processing record creation). As 
description in conjunction with the accompanying 55 new nodes are defined, they are stored in node library 
drawings, in which: 12 for later retrieval and reuse. Once a new service is 

FIG. 1/shows a block diagram of an intelligent tele- fully defined in terms of primitive or complex service 
phone network including a graphical telephone service nodes, a representation of that service definition is 
design and deployment system in accordance with the stored in a service definition storage facility 13. Once 
present invention; 60 the service nodes are assembled into a service logic tree 

FIG. 2 shows a flowchart of the service definition, or template, that template is stored as a call processing 
provisioning and implementation processes taking place record (CPR) in call processing record template library 
in the system of FIG. 1; 19. The templates in library 19 require only the specifi- 

FIG. 3 is a graphical representation of a display cation of certain customer-dependent variables required 
screen used to define new telephone service primitives 65 to fully implement the service for a particular customer, 
in the system of FIG. 1; A services management system 14 provides adminis- 

FIG. 4 is a graphical representation of a display trative control over a plurality of service control points 
screen used to define the allowable subset of telephone such as service control point 17 which actually imple- 
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ment the new services by exchanging network control 
messages with the switched telephone network 18. The 
details of the service control point 17, along with its 
interaction with the switched telephone network 18, are 



service management system 14 of FIG. 1 and imple- 
mented by the service control point 17 of FIG. 1 with- 
out the necessity of writing new service implementing 
code. As illustrated in FIG. 3, the user is presented with 



10 



, . . . , , — r ... w wajc. ujuauaicu ui riu. «?, uic user is presented Wlin 

J O *»t tti r o!^^»^t2 neC ! C0 P en ^ m ^ a PP^ ca ^ 0n of e 3 an on-screen form which requires that the user specify 

nw #»t a **** *: r ^ values for each of these properties. The cursor ini- 

tially is located at the first data field (NODE NAME:) 
and advances to successive data fields as the < enter > 
or <return> key is depressed. Once these properties 
have been specified, the user can store the completed 
node definition for the newly created node in a node 
library in store 12 (FIG. 1), using the command keys 
identified in the top portion of the screen display of 
FIG. 3. 

The properties captured by the node definition screen 
of FIG. 3 contain key information about the new node 
and, when necessary, can be translated and sent to the 
service control point 17 of FIG. 1 to drive a generic 
Call Processing Record (CPR) interpreter (such as that 



« I * — -VMMW- |fwui» Ji f \\j VV VIH- 

tomized for a particular customer or set of customers 
using network 18. Workstation 15 can, of course, be 
combined with workstation 10 if the two workstations 
are at the same location. 

The workstations 10 and 15 can be any modern work- 
station supporting graphical manipulation capability. 
One such workstation is the SUN 3/160 terminal run- 
ning under the SUN operating system and using the 
SUNVIEW® graphics environment. This environ- 



J. O. Boese et al. Since the structure and operation of 
the service control point 17 and the switched telephone 
system 18 comprise well-known telephone facilities, 
they will not be further described here. Sufficient to 
note that these elements are able to implement tele- 
phone network service primitives which can be utilized 
to realize telephone services and which are similar or 
identical to those disclosed in the aforementioned J. J. 
Bernardis and S. M. Lin patents and BSDB publication. 

Associated with the services management system 14 15 
is a customer data base 16 which contains detailed infor- 
mation concerning the customers utilizing telephone 
network 18. Also associated with services management 

system 14 is a further computer workstation 15 which ^ , iWTO ui g *.«;ura ys.r^ inierpreier mien as mat 
can be used to add customer preferences and other 20 disclosed in the aforementioned Bernardis patent), so 
customer specific data to the call processing record that it can support the use of this new node in any call 
templates defined m store 19. This addition of the cus- processing records that are created and provisioned for 
tomer specific data to a call processing record template services. Additional or supplemental properties, such as 
iscaUed service provisioning" and permits the service associated service control point call variables, node 
templates passed to service control point 17 to be cus- 25 connection rules and node translation rules, can be 

tomized for * ™rt,™i n r ~ M , ^ — added to the node library at a later time to completely 

characterize the meaning and intent of these operations 
at a particular services management system 14 and a 
particular service control point 17 (FIG. 1) in a generic 
30 manner. More particularly, a specific identification of 
the service implementing primitive in one or more ser- 
vice implementing network components which can be 
used to realize the node can be explicitly added to the 

_ 4 . — - . - node definition. The presence of such an identification 

ment provides window support, mouse control, and 35 of the actual code sequence in the service control point 
graphic creation and manipulation capability adequate would substantially simplify the design of the interpre- 
to implement the present invention. Many other modern tor program which translates the call processing record 
workstations, however, would likewise support imple- into actual service implementation. In this sense, the 
mentations of the present invention. nodes become elements of an extendible, high level 

The present invention will be better understood by 40 programming language for specifying telephone ser- 
considenngthefiowchartofFIG. 2. In FIG. 2 there is vices. 

shown a flowchart of the process for designing and In response to the NODE NAME prompt, the user 
deploying new services for telephone subscribers in supplies any unique name chosen for the new node. This 
accordance with the present invention. Three major name will hereafter be used to identify the node. This 
steps are involved, node definition, service definition 45 new node name can be thought of as a higher-level 
and call processing record creation. These steps will be abstraction representing a specific operation using pre- 

^TntT ^ , , . . defined ca}l Passing variables. Nodes can be diner 

The intended user of the process of FIG. 2 is the decision nodes or action nodes. The following node 

service creator, typically the telephone service pro- types, supplied in response to the NODE TYPE 

vider. As suggested in box 20 of FIG. 2, this person 50 prompt, are possible: 

must create the nodes to be used in new services. The 

new nodes are created dynamically by specifying the 

following properties of the new node. 

1. Node Name 

2. Node Type 55 

3. Data Type 

4. Node Rules 

5. "Other" Allowed 

6. Node Error Message 

7. Notes 60 
As is shown in detail in FIG. 3, a node definition 

screen can be used to capture the node properties as 
data items. The "Load," "Validate;* "Store," "Delete," 
"Browse," "Help," and "Quit" command buttons are 
utilized to access and process nodes as entities. The data 65 
acquisition fields are used to define new nodes by speci- 
fying the node name and the node properties. Using 
these properties, a node can be administered by the 



TABLE 1 


NODE TYPES 




ACTION 


DECISION 


NODES 


NODES 


Assignment Action 
Boolean Operation Action 
Collect Action 
Connect Action 
Concatenate Action 
CPR Access Action 
Diagnostic Action 
Return Action 
• Table Access Action 
Temporary Hand Over Action 
Terminate Action 


Branch Decision 
Integer Decision 
Percent Decision 
String Decision 



The node type selected provides information that can 
be used during call processing record validation and 
call processing record code generation. These node 
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types correspond to all of the basic types of actions and 
decisions that might be utilized in providing telephone 
special services. They are already programmed or pro- 
grammable into prior art service implementing network 
components such as service control point 17. Should a 
new type of node be required, however, it is necessary 
to specify the new type, and to provide generic imple- 
mentation of the activity of the new node type in the 
service control point 17. 

The node types have particular meaning to service 
control point 17, which must execute the call processing 
record in real time. Specifically, the node type informs 
service control point 17 what functions or call primi- 
tives are to be invoked. These node types thus represent 



8 



to 



The NOTES prompt permits a convenience field for 
the user. It can be used to note limitations on the node 
behavior, a general functional description of the node or 
any other information the user wishes to associate with 
the node definition. 

Also shown at the top of screen 30 of FIG. 3 are a 
series of command light buttons labeled "Load," "Vali- 
date," "Store," "Delete," "Browse," "Help," and 
"Quit." These command buttons are operated, for ex- 
ample, by a mouse-driven cursor, to accomplish the 
associated screen display control functions. For exam- 
ple, "Load" will load any particular previously existing 
node definition (e.g., for editing) simply by giving the 
node name and evoking the "Load" command. Simi- 



the "programmed capabilities" of service control point 15 larly, "Validate" performs the validation on the data 



17, which, when combined with the node name, repre- 
senting a particular pre-defined call variable in the ser- 
vice control point call processing execution environ- 
ment, enable service control point 17 to actually per- 
form the requested operations using the correct data. 

The DATA TYPE field specifies the format of the 
data that will be acceptable as input values for this node 
when this node is used in a call processing record. The 
data formats allowed are decimal numbers, alphanu- 
meric text, telephone numbers, trunk identifiers, vari- 
able data, and billing information. The data type is used 
during call processing record validation at the time the 
call processing record is "provisioned" by the specifica- 
tion of customer-dependent data values. 

To administer a call processing record, services man- 
agement system 14 of FIG. 1 must be able to determine 
whether valid values have been entered for the nodes in 
the call processing record tree. Therefore the user must 
specify the rules to be used when validating the input 
values for this node when this node is used in a call 
processing record. In accordance with the present in- 
vention, a regular expression can be used to represent 
the validation rules. Moreover, such validation rules 



20 



25 



30 



35 



entries made in response to the prompts. "Store" stores 
the newly defined node in the node library 12 of FIG. 1. 
The "Delete" command deletes the identified node 
definition from library 12. "Browse" allows the user to 
browse through all of the previously defined nodes, 
"Help" provides screens of useful ancillary information 
likely to be of assistance to the user during the node 
definition activity, and "Quit" allows the user to termi- 
nate the node definition activity. The implementation of 
these so-called "command buttons" are well-known in 
the art and will not be further described here. 

Returning to FIG. 2, the second box 21 represents the 
activity of defining a new service in terms of previously 
defined nodes. In this context, a "record" is a service 
definition and box 21 includes "Load," "Validate" and 
"Store" commands for these service definition records. 
In addition, box 21 includes "Canvas" commands. 
These commands permit the visual and graphical ma- 
nipulation of previously defined nodes into service defi- 
nitions. As can be better seen in FIG. 4, the left half of 
the screen 40 is the drawing area where visual represen- 
tations of previously defined nodes can be assembled 
into service definitions. The "Canvas" commands in- 



can be entered dynamically in the node definition as 40 elude "Clear" (to clear the canvas area), "Draw" (to 



opposed to hard coding them in a program. For exam- 
ple, to specify the validations for a queuing node, the 
user can specify the regular expression " (lifo|fifo)$". 
This expression states that the node can accept either 
"last in, first out" or "first in, first out" queue behavior 45 
as input values. 

In response to the OTHER ALLOWED, prompt, 
the user must specify whether the node can accept the 
word "other" as an input value. For example, if a day of 
the week node were defined and available for a particu- 50 
lar service, a call processing record would be con- 
structed with the day of the week node in the tree. If the 
input values for the day of the week node were specified 
as "Monday and Tuesday," then a second branch would 
need to be created to cover what should be done on 55 
Saturday, Sunday, Wednesday, Thursday and Friday. 
Rather than spell out the remaining days, the string 
"other" could be used. For some nodes "other" is not a 



prepare for manipulating items on the canvas), "Help" 
(to obtain screens of useful information to assist in the 
use of the system), and "Quit" (to terminate the service 
definition session). In addition, individual items in the 
canvas area can be manipulated with the commands 
"Select" (to select a particular node), "Add" (to add a 
selected node to the service definition), "View" (to 
view the node definition of the selected node), and 
"Delete" (to delete a node from the service definition). 
The intended user of the service definition process is 
the service creator. This creator utilizes the service 
definition process to define the subset of nodes in the 
node library that are to be used in a specific service. The 
user is presented with the form shown in FIG. 4 which 
enables the user to specify the nodes from the node 
library that are allowed for use by a specific service 
with a certain qualifier. A qualifier could, for example, 
be a specific area of service in the service provider's 
territory. With the functions described above, the use of 



sensible value. Therefore, during node definition, the 

user must indicate whether "other" is a valid input 60 any particular node in a service can be defined by a 
value or whether entering "other" should result in a service creator and administered by the service manage 
validation error. ------ 

In response to the NODE ERROR MESSAGE 
prompt, the user enters a string to be printed when an 
inappropriate input value is specified for a node during 65 
the provisioning of a call processing record. This allows 
"on the fly" validation of data entries during all suc- 
ceeding uses of this node definition. 



ment system 14. Once the allowable node names for a 
particular service have been specified, using the screen 
40 of FIG. 4, the user can store the service definition for 
the new service in service definition library 13 (FIG. 1). 
These service definitions can thereafter be edited, aug- 
mented or deleted from the service definition library 13 
whenever desired. 
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The service creation user can distribute the node 
library and the service definition library in store 13 to 
the generic service management system 14 for use in 
administering the new service. Services management 
system 14 will permit the use of only the specified subset 
of nodes in all call processing records that are created 
and provisioned for this particular service. Additional 
properties, such as service-specific node connection 

rules and node translation rules, can be added to the r 

«™cc definition tables at this time to completely and 10 ing node pMameter\"alu^s. At^^^'thV^e val^ 



providing a default service logic flow for the purpose of 
provisioning. Furthermore, the availability of service 
node definitions in store 13 will ensure that provisioning 
will support the use of only the creator-specified subset 
of nodes in any call processing records that are custom- 
ized and provisioned for this particular service. 

The service provider or the subscriber can also use 
the process illustrated in FIG. 5 to customize the default 
service template and to provision the service by provid- 



generically characterize the meaning and intent of these 
operations for the service management system 14. 

Returning to FIG. 2, the box 22 represents the proce- 
dures for "provisioning" the service defined in box 21. 
In this regard, the term "provisioning" means creating 
the logic tree representing the new service and custom- 
izing the defined service in terms of node parameter 
values. The screen 50 of FIG. 5 illustrates a mechanism 
for carrying out this process. The service creator can 



15 



ues supplied are validated dynamically by invoking the 
node validation rules specified for each node name in 
the node library. Additional node and service definition 
properties, such as node connection rules and node 
translation rules, can be specified to drive the validation 
and translation operations at the services management 
system 14 in a generic manner. 

The attached Appendix provides psuedocode for 
implementing the flowchart of FIG. 2. With this 



use ^process to define a default representation of the 20 pseudocode and the description herein provided, any 

service nfTmnntr »a ttrnnlat* s\f n/v4« i*«t A «.«^ nnAn * A ^ :„ ... K ^ M| J 



service offering as a template of nodes interconnected in 
a call processing record tree format. The allowed nodes 
for a particular service are the ones specified through 
the service definition process. The service provisioning 
user can use this process to customize the default ser- 25 
vice template and to provision the service with node 
parameter values. The user is presented with the visual 
programming tool illustrated in FIG. 5 to enable a 
graphical, user-friendly specification and input of the . 
appropriate service customization and provisioning 30 
information, based on service, qualifier and customer 
key information. The qualifier could be, for example, a 
specific area of service in the service provider's terri- 
tory. The screen of FIG. 5 provides record manipula- 
tion functions (Load Record, Validate Record, Store 35 
Record, and Translate Record), node manipulation 
functions (Place, Connect, Move, Edit, Disconnect, and 
Remove), and draw commands (Select, Clear, Help, 
Quit, and Redraw). 

With the above described functions, the user can 40 
define a service template of nodes interconnected in a 
call processing record tree format as a default represen- 
tation of the service offering. Furthermore, the true 
power of the present invention becomes evident when it 
is realized that the service creator can define modular 45 
templates of common reusable node-based logic as ser- 
vice features, which can then be added to the node 
library as nodes for reuse by other features and services. 
In effect, the present invention provides a mechanism 
for using the set of "programmable capabilities" avail- 50 
able at the service control point 17 and define reusable, 
user-friendly and high-level modules that enable easier 
and faster visual programming of the call processing 
logic. 

It should be noted that assemblies of low level nodes 55 
can be associated together into a higher level capability 
which, once given a name, can be retrieved, manipu- 
lated and used in creating new services just like a low 
level node. In this way, as time proceeds, the creation of 
new services becomes easier and easier since ever 60 
higher levels of service primitives become available for 
assembly into the new services. 

Once the default service template has been specified, 
the user can store the service template definition for the 
new service in service template definition store 19. The 65 
user can thereafter distribute these service template 
definition tables to the generic services management 
system 14 for use in administering the new service, 



person of ordinary skill in the programming art is able 
to fully implement the present invention. 

It should also be clear to those skilled in the art that 
further embodiments of the present invention may be 
made by those skilled in the art without departing from 
the teachings of the present invention. 



APPENDIX 
Pseudocode 

Node Definition Process Pseudocode 
invoke ('node— definition') 
do until (invoke ('quit 1 )) 
if (view (node—definition)) 
then input (node—name) 
invoke (load*) 

if (node— definition (node_name) in library 
then 

retrieve (node—definition (node— name)) 
display (node— definition (node— name)) 
else 

create (node— definition— window (node— name)) 
display (node— definition— window (node— name)) 
endif 

end—invoke 
endif 

if (specify (node— properties)) 
then 

set— default (field— values (node-name)) 
enter (field—values (node— name)) 
else 

if (modify (node— properties)) 

then update (field— values (node— name)) 
endif 
endif 

if (validation— check (node— name)) 
then 

invoke (Validate*) 
verify (node— name, field— entries, field—entry— 
combinations) 
end— invoke 
endif 

if (store (node— definition)) 
then 
invoke ('store') 
retrieve (node— definition (node— name)) 
overlay (node— definition, node— properties) 
store (overlay (node— name)) 
end— invoke 
endif 

if (delete (node— definition)) 
then 
invoke Cdelete') 
retrieve (node— definition (node_name)) 
delete (node— definition (node name)) 
end— invoke 
endif 
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APPENDIX 

Pseudocode 

if (browse (node—definition) 
then 
invoke ("browse*) 
display (node—properties) 
retrieve (node— definitions) 
display (node— definitions) 
end-invoke 
endif 
end-do 

Service Definition Process Pseudocode 
invoke ('service-definition') 
do until (invoke ('quit*)) 
if view (service—definition) 
then 

input (service—name, service— qualifier) 
invoke ('load') 

retrieve (service—definition (service— name, service— 

qualifier)) 

display (node— name— list) 
end— invoke 
endif 

if view (all— nodes) 
then 
invoke ("select*) 

generate (menu (all— nodes)) 
end— invoke 
endif 

if (select-node) 
then 
invoke C select*) 
select (desired— node, menu (all— nodes)) 
display (desired— node, current— node— display) 
end— invoke 
endif 

if use (current— node) 
then 
invoke Cadd*) 
position (current— node, canvas) 
add (current_node ? service—definition) 
end— invoke 
endif 

if disallow (current— node) 
then 
invoke f delect*) 
select (current-node) 
delete (selected— node) 
end— invoke 
endif 

if view (current— node—definition) 
then 
invoke (View*) 
select (current— node) 
display (node— definition, current— node) 
end-invoke 
endif 

if validate (service— definition) 
then 

invoke (Validate') 
verify (field— entries, service— definition) 
verify (field— entry— combinations, service— definitions) 

end— invoke 
endif 

if store (service— definition) 
then 
invoke (**tore*) 
retrieve (service— definition (service— name, service- 
qualifier)) 

overlay (service— definition (service— name, service— 

qualifer), canvas— nodes)) 
store (service-definition (service-name, service-qualifier)) 
end— invoke 
endif 

if clear (canvas— area) 
then 
invoke fclear*) 

clear (all— nodes, canvas— area) 
end— invoke 
endif 

if redraw (canvas— area) 



APPENDIX 
Pseudocode 

then 
invoke Cdraw*) 
clear (all— nodes, canvas— area) 
auto— invoke Clomd') 
end— invoke 
endif 
end— do 
CPR Input Process Pseudocode 
invoke CCPR— input*) 
do until invoke Oquit*) 

if view (existing— CPR tree) 

then 

input (service— name, qualifier— name, customer— name) 
invoke (*load*) 
retrieve (node— names (service— name, service— qualifier)) 
retrieve (node— definitions (node— names) 
retrieve (CPR— tree (service— name, service- 
qualifier, customer— name)) 
display CPH— tree (service— name, sericr qualifer, 
customer name)) 
end— invoke 
endif 

if view (allowed— nodes (service— name, service— qualifier)) 
then 
invoke ("select*) 

generate (menu (allowed— node— names)) 
end— invoke 
endif 

if select (allowed— node) 
then 
invoke Cselect*) 
identify (desired— node) 
display (desired— node, current-node) 
end— invoke 
endif 

if add (current— code, CPR— canvas) 
then 
invoke Cplace*) 
position (current— node, CPR— canvas) 
place (current— node, CPR__canvas) 
end— invoke 
endif 

if connect (node— name 1, node— name2, CPR_ canvas) 
then 
invoke (connect) 
select (from— node) 
select (to— node) 

draw— line (from— node, to— node 
end-invoke 
endif 

if move (node— name) 
then 
invoke (move) 
erase (node— name, old— location 
redraw (connections, old— location, new— location) 
end— invoke 
endif 

if edit (node— name— node— value) 
then 
invoke Cedit*) 
select (node— name) 
display (edit— menu) 
input (node— value) 
invoke Center*) 
erase (old— value) 
display (new— value) 
end— invoke 
end— invoke 
endif 

if disconnect (node— name) 
then 

invoke ('disconnect') 
select (node— name) 

erase— connection (node— name, node— parent) 
end— invoke 
endif 

if remove (node— name) 
then 

invoke ('remove*) 
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APPENDIX 
Pseudocode 



select (node— name) 

remove (node—name, children, connections) 
end— invoke 
endif 

if validate (CPR-node) 
then 

invoke Cvalidate*) 
for (each node in CPR_ tree) 
do 

validate (node— value, node— rule) 
end— do 

display (error— messages) 
correct (node— values, connections) 
end— invoke 
endif 

if store (CPR— tree) 
then 
invoke (*store*) 
retrieve (CPR— tree (service— name, service— qualifier, 

customer— name)) 
overlay (CPR—tree (service— name, service— qualifier, 

customer— name), CPR—tree (canvas— area)) 
store (CPR_tree, overlay) 
end— invoke 
endif 

if clear (canvas— area) 
then 
invoke ('clear') 

erase (canvas— area) 
end— invoke 
endif 

if redraw (canvas— area) 
then 
invoke fredraw*) 
erase (canvas— area) 
auto— invoke fload') 
end— invoke 
endif 
end— do 
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What is claimed is: 

1. A method for visually programming telephone 
services for implementation in a telephone network 40 
having a service control point, said method comprising 
the steps of 

defining new nodes of network service primitives for 

storage in a storage means, 
recalling from said storage means previously defined 45 

nodes, 

assembling a set of said defined new nodes and re- 
called nodes to be used in one of said telephone 
services wherein said assembled set of nodes can be 
stored as a service definition in a service definition 50 
library, 

graphically interrelating said assembled nodes into a 
logical graph representing a telephone service call 
processing sequence, 

storing said logical graph in a logical graph template 55 
library within said storage means to be used in 
providing the defined telephone service, 

retrieving a logical graph template from said template 
library when said telephone service is to. be provi- 
sioned for a customer, and 60 

specifying customer dependent variables in said logi- 
cal graph template for provisioning customer ser- 
vice 

wherein said logical graph template with said speci- 
fied customer dependent variables can be sent to a 65 
service control point for interpretation by an inter- 
pretive process to provide service. 



2. The method according to claim 1 wherein said step 
of defining new nodes comprises the step of 

specifying the name of one of said new nodes. 

3. The method according to claim 2 wherein said step 
of defining new nodes comprises the step of 

specifying the node type of said one new node. 

4. The method according to claim 2 wherein said step 
of defining new nodes comprises the step of 

specifying the data type of parameter values associ- 
ated with said one new node. 

5. The method according to claim 4 wherein said step 
of defining new nodes further comprises the steps of 

specifying validation rules for parameter values asso- 
ciated with said one new node, and 

specifying an error message to be displayed in re- 
sponse to the failure of either said data type or said 
parameter values to satisfy said validation rules. 

6. The method according to claim 1 wherein said step 
of defining new nodes comprises the step of 

displaying selected ones of the defined new nodes. 

7. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

adding either a new or previously defined node to 
said call processing sequence. 

8. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

deleting either a new or previously defined node from 
said call processing sequence. 

9. The method according to claim 1 wherein said step 
of graphically interrelating includes the step of 

interconnecting two of said set of assembled nodes in 
said call processing sequence. 

10. The method according to claim' 1 wherein said 
storage means comprises: 

a node library for storing said new and previously 
defined nodes, said service definition library and 
said template library. 

11. The method according to claim 1 wherein said 
logical graph can be defined as a complex node and 
stored for later use and recall in said node library. 

12. A system for defining software implemented ser- 
vices in a telephone network having a service control 
point and programmable facilities of having executable 
service primitives, said system comprising: 

a node data store for storing groupings of said service 
primitives as primitive nodes; 

a service definition data store; 

a call processing record template store; 

a graphical user input and display device; and 

service creation process means for retrieving from 
said node data store any number of said nodes and 
displaying said nodes on said graphical user input 
and display device as a graphical symbol wherein a 
user using said graphical user display device can 
select from said nodes a set for defining a service 
and store said set of nodes together as a service 
definition in said service definition data store, ma- 
nipulate said set of nodes into a graphical abstrac- 
tion of a logical service process, and store said 
graphical abstraction of a logical service process as 
a call processing record in said call processing 
record template store, and wherein customer data 
can be added to said call processing record tem- 
plate store and sent to said service control point to 
provision services for a customer. 

13. The system according to claim 12 wherein said 
service creation process means further comprises means 
for defining at least one new node of service primitives 
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by specifying a node name, a node type, and a new set 
of node properties comprised of parameter values and 
means for storing said new node in said node data store. 

14. The system according to claim 13 wherein said 
service creation process means further comprises means 
for modifying said nodes by changing the values for 
properties that make up said nodes. 

15. A system for defining software implemented ser- 
vices in a telephone network having programmable 
facilities consisting of executable service primitives, said 
system comprising: 

a node data store for storing groupings of said service 
primitives as primitive nodes; 

a service definition data store; 

a call processing record store; 

a graphical user input and display device; and 

service creation process means for retrieving from 
said node data store any number of said nodes and 
displaying said nodes on said graphical user input 
and display device as a graphical symbol, said ser- 
vice creation process means comprising: 
means for defining at least one new node of service 
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means for specifying an error message to be 
displayed in response to the failure of either 
said node type or said parameter values to 
satisfy validation rules; and 
means for storing said new node in said node data 

store, 

wherein a user using said graphical user display de- 
vice can select from said nodes a set for defining a 
service and store said selected set of nodes defined 
as a service in said service definition data store, 
manipulate said set of nodes into a graphical ab- 
straction of a logical service process creating a call 
processing record logic tree and store said call 
processing record logic tree in said call processing 
record data store, and wherein said user can add to 
said graphical abstraction of a logical service pro- 
cess customer data creating a customized call pro- 
cessing record to be sent to a service control point 
to be executed when service is requested. 
16. The system according to claim 15 wherein said 
sendee creation process means further includes means 
for adding a node from said node data store to said call 
processing record logic tree. 



... 17. The system according to claim 16 wherein said 

primitives by specifying a node name, a node 2 5 service creation process means further includes means 

type, and a new set of node properties comprised for deleting a node from said call processing record 

of parameter values said means for defining at logic tree. 

least one new node further comprising; * * * * * 
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